A server is typically contacted by a client when data is requested from the server. Thus, the server's primary responsibility is to respond to each server request with the requested data. Various protocols are available to enable a client to submit a request to a server.
As one example, the Remote Procedure Call (RPC) protocol is generally used to transmit a request from a client to a server, which is typically referred to as a “remote procedure call.” Generally, the client includes a RPC stub that serves as an interface to the server. Specifically, the stub packages the parameters that are sent to the appropriate server when the client calls that particular service. In this manner, a RPC is used by a client to invoke a service provided by a server.
Generally, each server has its own broker, which is called to initiate a client-server relationship. Specifically, a RPCBIND function is called to invoke a RPC relationship. The server provides the broker the name of the services provided by the server. In addition, the client will inform the broker that it is attempting to locate a requested service.
When the client sends a RPCBIND request to the broker, the broker performs a lookup for the requested service, and provides a “handle” to the service to the client. The client may thereafter call the service by using the handle name and the service name. For example, the handle H1 may be provided to the client for the service “get-time,” enabling the client to call the service via a call such as H1.get-time.
When the server crashes or becomes non-functional, the handle is no longer valid for the purposes of invoking the server's services. Upon receiving an error message when the service is called, the client then performs a second lookup for the requested service. In response to this second lookup, a second handle is provided to the client in the event that another second server provides the same service. The client may then access this second server via this second handle.
Traditionally, RPC is machine-based. Specifically, each server runs RPC and includes its own broker. In order to obtain the port number of the machine to initiate a particular service, it must contact the broker. Since brokers are separately implemented on each server, the client must know ahead of time which machine is providing the service in order to contact the correct broker.
When a server becomes non-functional, the client must actively locate another server that provides the same service as the initial server. In accordance with various embodiments of the invention, a redundant server is located transparently to the client and a binding is performed automatically.
Typically, RPC bind is implemented on each server. As described above, typically, each server implements it's own broker. Specifically, each server implements its own broker and runs RPC to enable the server to register its services with the broker using RPCBIND. Thus, in order to call the services provided by a particular server, a client typically needs to call the broker on the appropriate server in order to obtain the information needed (e.g., port number) in order to establish a connection with the server. This is particularly important for protocols such as TCP/IP and UDP/IP, which require a port number in order to establish a connection.
Typically, if a server crashes or becomes non-functional, a client calling a service provided by that server will receive an error when that service is called. A server may become non-functional in a variety of circumstances. For instance, a “failover” occurs when a particular server fails and a service is then made available on a different server. As another example, a particular service may simply be moved to another server, resulting in a “switchover.” In either case, the client must then locate another server that provides the same service.